[Chapter 11] 11.4 Rule Set Hubset
Author: Bryan Costales & Eric Allman
Date: 1999-01-06T18:36:37Z

#

| Chapter 11 Rule Sets 1 and S= |

## 11.4 Rule Set Hubset

Place the following new rule after rule set 3 in the client.cf file:

>     S3 # preprocessing for all rule sets
>     R$* <> $*                    $n             handle <> error address
>     R$* < $* < $* > $* > $*      $2<$3>$4       de-nest brackets
>     R$* < $* > $*                $2             basic RFC822 parsing

>     SHubset # Rewrite the sender for the hub                      new

At this point you may be wondering why we can give this rule set a symbolic name, when the earlier rule sets (0 and 3) had numeric names. The answer lies inside sendmail. Recall that rule set numbers 0 through 5 have special internal meaning to sendmail. Part of that meaning is their names. The sendmail program recognizes those special rules only by number. If you were to give them names instead of numbers, sendmail would not recognize them, and your configuration file would cease to work.

On the other hand, beginning with V8.7 sendmail, you may both specify a rule set and give it a symbolic name. Internally, sendmail converts that name to a number (a high one such as 199) and internally refers to it by number. The conversion process ensures that each name will correspond to a unique number.

Now that we've named `Hubset`, let's put some rules in it.

### 11.4.1 Rewrite the Lone Username

The sender's address can take several forms. It can be a user's login name, such as gw or ben. It can be a user at a short hostname, such as gw@wash or ben@fbi. It can be a user at a fully qualified name such as gw@wash.dc.gov or ben@fbi.dc.gov.

The `Hubset` rule set first looks for an address that is just a simple user's name, such as gw, and makes it appear as though it is from the mail hub. To do this, you need a new LHS wildcard operator, `$-`. The `$-` wildcard operator matches exactly one token in the workspace. The first rule in the `Hubset` rule set uses the `$-` wildcard operator like this:

>     SHubset # Rewrite the sender for the hub
>     R$-                          $@ $1@${HUB}   user -> user@hub     new

Because `$-` is the only wildcard operator in the LHS, a match occurs only if the workspace contains a single token:

>     $-matches   "you"
>     $-does not match   "you" "@" "localhost"

This LHS is used to look for an address that contains only a user's login name. When such a match is found, the RHS (`$@ $1@${HUB}`) rewrites that address by appending an `@` and the name of the mail hub machine, which was stored in the `${HUB}` macro.

The RHS contains two rewrite operators, one that you have seen already and one that you haven't:

>     $1positional operator (you have seen this)
>     $@return immediately (new)

When `$@` begins (prefixes) the RHS of any rule, it tells sendmail to return (exit the current rule set) immediately after it has rewritten the workspace. If the `$@` prefix did not appear at the start of the RHS, sendmail would rewrite the workspace and then evaluate the LHS again. The `$@` also prevents the workspace from being carried down to any additional rules in the current rule set. An immediate return from this rule is desirable because additional rules might corrupt the now correct workspace.

The actual rewriting is done by `$1@${HUB}`. The `$1`, which you have seen before, takes the username matched by the LHS of `$-` (the first and only wildcard operator, thus `$1`). Then an `@` character is appended. Then the `${HUB}` macro is appended to the workspace.

The `${HUB}` macro contains the address of the mail hub machine as it is known to the outside world. This is different from the `${REMOTE}` macro that you defined earlier, which contains the address of the mail hub machine as it is known to the internal network. Before you can use the value of `${HUB}`, you need to define it in the client.cf file:

>     # Defined macros
>     D{REMOTE}mailhost              # The name of the mail hub
>     D{HUB}mail.us.edu              # Hub as known to the outside world     new

This new macro definition places the text `mail.us.edu` into the macro named `{HUB}`. Now the RHS of `$1@${HUB}` will rewrite the workspace into

>     you @ mail . us . edu

>      $1 @ ${HUB}

This is exactly what is wanted. Remember that the `Hubset` rule set handles only sender addresses. Any sender address that consists of nothing more than the name of a user will be rewritten to appear to come from the mail hub. Table 11.1 shows the three LHS wildcard operators that you now know.

Table 11.1: Three LHS Wildcard Operators
Wildcard | Description
--- | ---
`$+` | Match one or more tokens
`$*` | Match zero or more tokens
`$-` | Match exactly one token

### 11.4.2 A Word About ${HUB}

In the client.cf file, `${REMOTE}` is defined to be the name of the hub machine as it is known internally to your network. `${HUB}` is defined to be the name of that same machine as it is known to the outside world. Note that both names could be (and probably will be) the same at your site.

The important point about `${REMOTE}` is that it contains a symbolic name, such as mailhost. This allows the machine that is used as the hub to be easily changed should the need arise. As your site becomes larger and more complex, you might want to have several hubs for routing messages to the outside world. Or you might want to have one machine handle all outgoing mail and another handle all incoming mail. Using a symbolic name makes such changes easy.

The important point about `${HUB}`, on the other hand, is that it contains a fully qualified domain name that is listed with the Domain Name System or the UUCP maps and is known to all other sites in the world. This is the host part of the address that other sites will use when they reply to mail sent from the hub.

Remember that a name such as you@ with the value of `${HUB}` added makes the address of the local sender (you) look as though it is from the hub (mail.us.edu). When someone at another site replies to this address, the reply will go to the hub rather than to the local client. This is an important distinction, because the client machine may (by design) be unable to receive mail (more on this later).

11.3 All Mail from the Hub |  | 11.5 Testing So Far